System Engineering and Marketing

Using models to capture requirements and to initialize operations concepts for new product development has received attention in the Eighth Annual INCOSE Symposium in Vancouver, with the result that the requirements handling process itself is more efficient. The document-driven design methodology is replaced with models that state subsystem-level requirements in executable form. However, most "models" are product-focused and do not incorporate a methodology to clarify and quantify customer needs in relation to that product. This paper outlines a method that has been used by the authors in projects varying in size from church building programs to large satellite programs and involves both marketing and system engineering disciplines. INTRODUCTION This paper is the first in a series that seeks to quantify how best to proceed with the up-front development of systems that exhibit competitive advantages and meet customer needs. Those two objectives are met during the stage of the system engineering process called requirements clarification. Requirements clarification in turn, is the concatenation of two ideas which will be developed further in the paper: 1. Developing the Customer Preference Surface-CPS 2. Implementing the Design Reference System-DRS We will focus on techniques from economics, marketing, and systems engineering to clarify these concepts. First, we look at the four P’s of marketing, the five C’s of a system engineered product and their intersection before we describe the CPS and the DRS. The Four P’s of Marketing. The basics of marketing are summarized by four items. Product: What you are developing Price: The competitive, market-evaluated "worth" of the product Promotion: How you move the product from inception to consumer, and how you create demand for the product Place: Where your product needs to be. Every activity that is part of the product development life cycle fits into one of these categories. This paper emphasizes product and promotion activity with some reference to price. In marketing or promotion, we are concentrating on quantifying the demand for the product, which will lead to development of the Customer Preference Surface and an explicit, 3-D representation of his requirements. Requirements are not explicitly stated as part of these Four P’s. As implicit factors, the requirements are found in the Product and Price elements. A major feature of this method is that the requirements will appear and they will appear to your company’s advantage when the systems engineer helps marketing place them into the equation. The customer is not sure exactly what the requirements are, but certainly thinks he knows what he wants. The Five C’s of a System Engineered Product. The features of a well-engineered system product are summarized below: Complete: No missing pieces Consistent: The pieces fit one another and the task at hand Correct: The assembly fits the intended use Cost-Effective: There is an economy evident Congruent: There is synergy between the elements of the larger assemblies. These attributes are valid for all phases of the project life cycle: requirements development, design, manufacturing, verification, test, operations, and maintenance. Nevertheless, there still needs to be a way to connect the Four P’s to the Five C’s. CORU. Elements of the two disciplines intersect, and the intersection is characterized by Customer Oriented Requirements Understanding-CORU. If you understand your customer you can be an effective communicator of the Products she wants, the Price she’s willing to pay, the place she needs it, and the Promotion it will take to convince her that you and your company are the right people to provide it. Getting to "right" can be an uncharted course unless you have a process for people to follow to get to the solution of improved sales per employee, to the right system-engineered solution for a customer need, and the right marketing approach. Figure 1. What is the Intersection? Understand your customer’s requirements (system engineering) and you understand your customer (marketing). As a result, we are now going to look at a process that a team (of as few as two) front-end systems engineers and marketing professionals together can use to systematically become winners in the product innovation and introduction business. The process for getting through the intersection to a product is: 1. Begin with the Customer Preference Surface 2. Develop the Design Reference System 3. Bring the two into contact with a planned approach--a marketing plan or customer contact plan 4. Listen for the feedback 5. Adjust your approach It begins with the C in CORU--the customer and her preference surface. THE CUSTOMER PREFERENCE SURFACE The notion of a customer preference surface has its roots in quantitative econometrics and portfolio analysis techniques where it is possible, through quadratic least squares formulae to specify a mix of securities that will (ceterus paribus) satisfy a multitude of risk-return criteria. The mathematics aside for a minute, it’s important to concede the EXISTENCE of such a surface. It is "ndimensional", where "n" CAN BE the number of parameters and their values that you believe--first guess--are important to your customer, But since we have trouble visualizing surfaces in "n" dimensions, let’s try 3 dimensions, plus time. The customer preference surface may have axes of quantity, quality and cost, and it may be that you can specify these three coordinates with a preference value so that the preference matrix for any time "t" looks like P(x,y,z,t=0) and the elements have value of preference or utility, p(1,2,1,t=0) = 4 for example. Economics tells us that the largest preference isoquant will form a surface in "n-dimensional" space with the property that operating curves of, in this case, quality quantity, and price which are tangent to the surface will maximize the customer preference for some minimized quantity (like cost) which is important to you and your customer’s system specification (Fig. 2). There are some real caveats to this notion. The customer preference surface contains the locus of all points in requirements space, which maximize the utility of the customer community. It is, however, 1. Unknown to you 2. Unknown to an individual customer, and to the community, to a degree 3. "n" dimensional, tough to model 4. Variable in time and space--example, Do requirements ever change? 5. Has traps (local minima) 6. Will contain constraints--interfaces and standard products The customer preference surface is constructed to quantitatively estimate the value of various designs to the customer community in terms of his utilityspace. An idea similar to the Customer preference surface needs to be developed for the system product space Figure 2. Visualization of the Customer Preference Surface THE DESIGN REFERENCE SYSTEM At this point in the product development phase the team pulls together a Design Reference System before system engineers do a detailed point design with extensive requirements flowdown from a preliminary specification, and before market analysts construct detail models of the pseudo customer preference surface. This Design Reference System (or DRS) will eventually be the Baseline, and it will eventually, if successful, be tangent (or as close to congruent to an area of the CPS) to the CPS. Gonzales and Lovelace (98) state that some authors use the term "conceptual model" or "mental model" interchangeably, and contend that "a conceptual model is an extremely useful communication tool at the onset of a project.... The conceptual model allows the team to reason about and understand the domain area in which the system will be used." It can contain standard processes and procedures, it should represent your core competencies while deemphasizing your competitor’s strengths, and it is formed from the range and domain of requirements and functions, which characterize the system. It should be a "shared vision" and it should integrate the mental models of the stakeholders. It should have as many of the 5 C’s as possible--complete, consistent, correct, cost-effective-congruent (and it should work....) But it is NOT THE BASELINE YET. It is constructed for purposes of understanding and is not to be defended. It is built to die in the crucible of requirements clarification. It is represented as a plane in Fig 3. It is brought into the neighborhood of the customer preference surface through planned promotion and targeted discussion. It contains requirements issues, competitive strengths and weaknesses, some good ideas, and some trial balloons. Figure 3. The Design Reference System as a Plane As the design reference system in Fig. 3 is brought into contact with the CPS, is there a difference between contacting at Point A vs. B. From the customer preference surface point of view, the answer is "no". Indeed the difference between Points A and B is product differentiation, but both points meet the customer needs. Other coordinate systems not shown here are ones that determine your competitive advantage. Looking at Point P in the figure, we have an example of a suboptimal system where the cost may be too high or performance may be too low. The CPS may not be in same coordinates as your system. For example, a customer in the weather forecasting business may be asking for data with a 1km accuracy. Your system needs to sense some energy in the atmosphere to achieve this. Now the sensing performance measures are NEDT, jitter, etc., all of which draw a blank stare from the customer making weather forecasts when you ask her what her requirements are for these parameters. We need to help customer understand by providing expertise and investments in systems engineering modeling and analysis that transform the DRS coordinates into CPS coordinates. There are a 1000 different ways to bring the DRS into contact. What is the chance that your DRS is what customer has in mind? Can a systems engineer come into marketing discussions to tell / lead / influence / help the customer understand how design parameters impact her bottom line (the CPS). The CPS is her baby. She really doesn’t know everything about her baby, but she does know that bringing a hot iron into contact with baby will cause screams. In this realm, marketing and system engineering work together. The marketing plan picks up the DRS and brings it into contact with the CPS and through the CORU concept all of the team members listen for feedback and write down customer comments verbatim-comments are collected, digested, filtered, and maybe, the DRS is adjusted. The important element to understand is that this is a feedback and respond (do not REACT--have planned responses for predicted feedback). Listen for SCREAMS--the amount and frequency of the feedback is proportional to the error. What error? The customer community is composed of many individuals, each of whom has an idea of the CPS in his or her vicinity--and only assumes what the perfect DRS should be. As Richard Wray reports, "an analysis of customer technical NEEDS must be the basis of understanding the technical requirements, desires and expectations, all of which must be resolved." The feedback you get will be proportional to the perceived error--but the feedback also will be proportional to the frequency of contact, will contain error itself, and therefore needs filtering and validation and response. The response can range for mere acknowledgment to overt adjustment of the Design Reference System. The objective in any adjustment of the DRS is to improve tangency, or congruency. Figure 4. Bringing the DRS into Contact with the CPS Now, interestingly enough, you can also improve congruency by changing or influencing the customer preference surface, and ideally, you can do both, simultaneously--a great tactic that distances you from your competition. However, before we delve too much further into moving the CPS, lets look into the Tools, Techniques, and the ultimate Target which can unite system engineering and marketing in a variety of different enterprises and settings. Some of the tools to apply are: 1) Requirements analysis and flowdown. Done with insight these functions should identify issues and sensitivities that can help further trades before going to a point design 2) QFD, Quality Functional Deployment--the Voice of the customer targets understanding customer needs and sensitivities. Requirements flowdown is generally done on the product side, whereas needs analysis is done on the customer side 3) Functional analysis--Done in conjunction with the requirements flowdown, functional analysis also identifies key areas where economies can be engineered across segment boundaries and equivalent functions can be performed at alternative sites or nodes in the product hierarchy. 4) Technical Analysis--computes the operating characteristics of the DRS. For any of the dimensions of the CPS, you have to know how the DRS is performing. 5) Production and Manufacturing--these areas have to weigh in for risk and cost. Once these tools and insights are available and Figure 5. Adjust the DRS--or NOT utilized for the DRS, your team can decide whether to adjust the DRS or influence the CPS. There are basically only these two options available because staying at the initial point will allow your competition to eliminate your competitive advantages. If you choose to adjust your DRS in response to the synthesized feedback, do it along an operating line of your core competency. Otherwise, you will be moving closer to your competitor’s solution and away from product differentiation. An alternative technique is to "get inside" the customer’s preference surface and alter it to conform to your strengths. (Fig. 5). There are legal (protests, etc.) ways of doing this but the best way is through key technology experts who are acknowledged experts in the areas of interest to the customer community. These experts can adjust the CPS (generally moving it outward) in the areas which represent your technologies and are the result of your internal investments. Examples include the hugely successful series of INTEL introductions of processors. Our consumer expectation CPS no longer has 33 or 66 MHz processors (at any price) on the surface. Their effective product promotions have generally kept prices stable while driving up product capabilities. In other areas, we now see 7.6 Gbyte disks for under $200. Experts with credibility in the customer domain help you to do this. Now, the competition might figure this out where they hear from your common customer that the requirements are changing. But if we change the CPS with speed and strength, they will be inside the CPS and thinking they are on tangency point of old requirements. Whether you choose to adjust the DRS or alter the CPS or do both, the target is the same. 1) A DRS that is 5C’s better than your competitors’ and can now be a baseline 2) A competitive position that’s affordable and a contractual position that really meets customer objectives—CORU 3) A measurable contribution to an improvement in the sales per employee per year. A NUMERICAL EXAMPLE Bringing the DRS into contact with the customer preference surface is demonstrated in the numerical example shown in Figure 6. The DRS Operating Curve shows how the customer's utility (Bang) increases with the amount of investment in our DRS (Bucks). The customer is indifferent to any system whose operating curve is tangent to his or her preference surface. Two preference surfaces are shown the first, which has a bang per buck value of 0.05, is tangent to the DRS operating curve and from our previous discussion shows that buying 40 Bucks worth of our DRS is optimal. Figure 6. Numerical Example of Bringing the DRS into Contact with the Customer Preference Surface A preference surface with a lower bang per buck value of 0.04 is shown that crosses the DRS Operating curve at two points, both of which have the same suboptimal bang per buck value – one is the cheaper system where 30 bucks are spent and less bang is derived, and the other is a high-priced system with an 80 buck price tag and higher utility than the optimal system. An inferior DRS Operating below and to the right of the DRS Operating curve shown would be optimal for a customer whose preferences were represented by the Bang per Buck = 0.04 line. The readers may have seen many a simple numerical example from their Economics 101 days such as shown in Figure 6, but perhaps they are a bit skeptical that the real world can yield data that can be laid out so nicely and provide a crisp conclusion for an actual investment decision. We proceed to demonstrate that it is feasible to develop such data and insight in real world systems. The National Polar-Orbiting Operational Environmental Satellite System (NPOESS) is planned to replace existing satellites developed separately for the DOD DMSP (Defense Meteorological Satellite Program) and NOAA POES (Polar-orbiting Operational Environmental Satellites) program. More attention has been given to documenting impacts of design requirements on end-user utility for this system. Kenley and Coffman (1999) presented the error budget process used to flow down measurement accuracy requirements from missionlevel user requirements to sensor-level technology requirements. Figure 7 shows a cost-benefit comparison derived from their results. The Advanced, Very High Resolution Radiometer (AVHRR) is the current infrared sensor used on NOAA satellites. The analysis shows that the AVHRR has only a 5% probability of correct identification of thin cirrus Figure 7. A Real World Numerical Example from Weather Forecasting clouds at a cost of $6 million. For the NPOESS system, the proposed new infrared sensor is the OASIS, a better-calibrated instrument with a smaller pixel size. It was shown to have capability to meet the user mission need to identify thin cirrus clouds correctly 95% of the time at a cost of $25 million. The utility of the improved sensor is proportional to the reduction in the expected number of false alarms that results from using the OASIS to replace the AVHRR. The false alarm reduction is: 1 / 0.05 1/ 0.95 = 18.89 The justification of the development costs for the new sensor is clearly demonstrated by the dramatic improvement in utility-cost ratio. The subtleties arise when considering sensor design trade-offs in the domain of the OASIS performance. From Figure 7, a sensor that has only an 85% correct identification performance at a discounted price of $22.5 million is shown to have a better utility-cost ratio, and the slightly higher powered 95% performance unit at $27.5 million is shown to be a loser in the utility-cost game. This is where understanding the customer's preferences at a deeper level can help change the customer preference surface. The utility calculated in Figure 7 is based on the false alarm rate reduction. The false alarm reductions achieved by the $22.5, $25, and $27.5 million units are 18.82, 18.89, and 18.95 respectively. The differences in the false alarm reduction are miniscule, but if we understand that for weather forecasting a false alarm can cost to the end user $2million for firing a single laser-guided weapon, $4 million per launch of a Tomahawk missile, and $22.5 million for hurricane evacuation, we can convert the differences in false alarm rates to millions of dollars in cost savings over the life time of the sensor to justify spending $2.5 million more for the slightly higher powered unit that produces 95% correct identification of clouds. SUMMARY AND CONCLUSIONS Having viewed the DRS and the CPS from the perspective of competitive advantage, it’s time to distance yourself from the competition by moving both the DRS and the CPS in the directions that favor your position. Diagrammatically, it looks like Figure 8. In reality, it’s the result of your focus on innovative ways to solve your customer’s problems, using your strengths 1) System engineering of complex systems should include the customer as a vital part of system development. Customer Oriented Requirements Understanding--CORU 2) Marketing complex systems in a fractionated diverse customer community requires a systematic method for feedback and analysis of results 3) Investing in core competencies or ones that make you unique can be the best way to influence the Customer Preference Surface. 4) The CPS and DRS changes must be done in a way that improves your competitive advantage. Know your competition and your industry. 5) In building the DRS and the CPS utilize both system engineers and marketing professionals in a team atmosphere. Figure 8, The Ultimate Strategy? REFERENCESKenley, C.R., and Coffman, R.B., " The Error BudgetProcess: An Example from EnvironmentalRemote Sensing ", Systems Engineering, pp.275-282.Gonzales, R.M., and Lovelace, N., "UsingStakeholder Mental Models to Create AnIntegrated Conceptual Model for Systems", Proceedings of the Eighth Annual International Symposium of the International Council on Systems Engineering, (Vancouver, BC, July 26-30, 1998), pp. 275-282.Wall, S.D., Baker, J.D., Krajewski, J.A., and SmithD.B., "Implementation of System RequirementsModels for Space Missions", Proceedings of the Eighth Annual International Symposium of the International Council on Systems Engineering (Vancouver, BC, July 26-30, 1998), pp. 285-292.Wray, Richard B., "Developing Technical Strategywith Systems Engineering", ", Proceedings of the Eighth Annual International Symposium of the International Council on Systems Engineering,(Vancouver, BC, July 26-30, 1998), pp. 833-844. BIOGRAPHIESDavid J. Paul holds an M.B.A in ManagementSciences and an M.S. in Meteorology andMathematics, and a B.S in Chemical Engineering.He has completed all the course work for an MS inComputer Science and is a graduate of the Air Forceand Navy War Colleges, the Air Force Command andStaff and Squadron Officers School. He is an AirForce Reserve Colonel at the Air Force SpaceCommand, and has over 30 years experience inaerospace and environmental systems engineering.His current mission is to provide meteorological datasystem users with insight to the value of theirproducts. He is a member of AmericanMeteorological Society, the American ManagementAssociation and the San Francisco Bay Area Chapterof INCOSE, and is a published author of severalpapers in many discipline areas.C. Robert Kenley holds a Ph.D. and M.S.Engineering-Economic Systems, a M.S. in Statistics,and a S.B. in Management. He is an independentconsultant, and has 15 years experience in aerospaceand environmental systems engineering. His currentmission is to make his clients' best decision obvious.He is a member of the US Department of Energy’sPlutonium Focus Area Technical Advisory Panel andthe San Francisco Bay Area Chapter of INCOSE, andis a published author of several papers and journalarticles.